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Les 


Introduction 


This document provides encapsulation formats and semantics for 
emulating SONET/SDH circuits and services over MPLS. 


Scope 


The generic requirements and architecture for Pseudowire Emulation 
Edge-to-Edge (PWE3) are described in [PWE3-REQ] and [PWE3-ARCH]. 
Additional requirements for emulation of SONET/SDH and lower-rate TDM 
circuits are described in [PWE3-TDM-REQ]. 


This document provides encapsulation formats and semantics for 
emulating SONET/SDH circuits and services over MPLS packet-switched 
networks (PSNs). Emulation of the following digital signals are 
defined: 


1. Synchronous Payload Envelope (SPE) /Virtual Container (VC-n): STS- 
1/VC-3, STS-3c/VC-4, STS-12c/VC-4-4c, STS-48c/VC-4-16c, STS-192c/ 
VC-4-64c, etc. 


2. Virtual Tributary (VT)/Virtual Container (VC-n): VT1.5/VC-11, 
VT2/VC-12, VT3, VI6/VC-2 


For the remainder of this document, these constructs are referred to 
as SONET/SDH channels. 


Requirements Notation 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


Acronyms 


ADM Add Drop Multiplexer 


AIS Alarm Indication Signal 

APM Adaptive Pointer Management 

AU-n Administrative Unit-n (SDH) 

AUG Administrative Unit Group (SDH) 
BIP Bit Interleaved Parity 

BITS Building Integrated Timing Supply 
CEP Circuit Emulation over Packet 

DBA Dynamic Bandwidth Allocation 

EBM Equipped Bit Mask 


EPAR Explicit Pointer Adjustment Relay 
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LOF 
LOS 
LTE 
POH 
PSN 
PTE 
PW 
RDI 
SDH 
SONE 
SPE 
STM- 
STS- 
TDM 
TOH 
TU-n 
TUG- 
UNEQ 
VC-n 
VT 
VIG 


2 


Loss 
Loss 
Line 
Path 


SONET/SDH Circuit Emulation 


of Frame 
of Signal 
Terminating Equipment 
Overhead 


Packet Switched Network 


Path 


Terminating Equipment 


Pseudowire 
Remote Defect Indication 
Synchronous Digital Hierarchy 
T Synchronous Optical Network 
Synchronous Payload Envelope 
n Synchronous Transport Module-n (SDH) 
n Synchronous Transport Signal-n (SONET) 


Time 


Division Multiplexing 


Transport Overhead 
Tributary Unit-n (SDH) 

n Tributary Unit Group-n (SDH) 
Unequipped 
Virtual Container-n (SDH) 
Virtual Tributary (SONET) 
Virtual Tributary Group (SONET) 


5. CEP Encapsulation Format 


April 2007 


In order to transport SONET/SDH circuits through a packet-oriented 
ork, the SPE (or VT) is broken into fragments, 
and optionally an RTP header are prepended to each fragment. 


netw 
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The basic CEP packet appears in Figure 1. 


HZ - 5-5-5 5-5-5 ------- + 
| PSN and Multiplexing Layer | 
| Headers | 
HZ - 5-5-5 == 5-5-5 ------- + 
| CEP Header | 
HZ 7-5-5 5-55-55 == 5-5 ---- + 

RTP Header 

(RFC 3550) 
HZ 7-55-55 = 5-5-5 == 5 === ---- + 
| | 
| | 
| SONET/SDH | 
| Fragment | 
HZ - 5-7-5 55-5 = 5-5-5 ------- + 


Figure 1: Basic CEP Packet 
5.1. SONET/SDH Fragment 


The SONET/SDH fragments MUST be byte aligned with the SONET/SDH SPE 
or VT. The first bit received from each byte of the SONET/SDH MUST 
be the Most Significant Bit of each byte in the SONET/SDH fragment. 


SONET/SDH bytes are placed into the SONET/SDH fragment in the same 
order in which they are received. 


SONET/SDH optical interfaces use binary coding and therefore are 
scrambled prior to transmission to ensure an adequate number of 
transitions. For clarity, this scrambling is referred to as physical 
layer scrambling/descrambling. 


In addition, many payload formats (such as for Asynchronous Transfer 
Mode (ATM) and High-Level Data Link Control (HDLC)) include an 
additional layer of scrambling to provide protection against 
transition density violations within the SPEs. This function is 
referred to as payload scrambling/unscrambling. 


CEP assumes that physical layer scrambling/unscrambling occurs as 


part of the SONET/SDH section/line termination Native Service 
Processing (NSP) functions. 
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However, CEP makes no assumption about payload scrambling. The 
SONET/SDH fragments MUST be constructed without knowledge or 
processing of any incidental payload scrambling. 


CEP implementations MUST include the H3 (or V3) byte in the SONET/SDH 
fragment during negative pointer adjustment events, and MUST remove 
the stuff byte from the SONET/SDH fragment during positive pointer 
adjustment events. 


VT emulation implementations MUST NOT carry the VT pointer bytes V1, 
V2, V3, and V4 as part of the CEP payload. The only exception is the 
carriage of V3 during negative pointer adjustment as described above. 


All CEP SPE implementations MUST support a packet size of 783 bytes 
and MAY support other packet sizes. 


VT emulation implementations MUST support payload size of full VT 
super-frame, and MAY support 1/2 and 1/4 VT super-frame payload 


sizes. 


Table 1 below describes single super-frame payload size per VT type. 


4+------------- 4+-------------- + 
| VT type | Size (Bytes) | 
4+------------- 4+-------------- + 
| vT1.5/vc-11 | 104 | 
| VT2/VC-12 | 140 | 
VT3 212 
VT6/VC-2 428 
4+------------- 4+-------------- + 


Table 1: VT Super-Frame Payload Sizes 


OPTIONAL SONET/SDH Fragment formats have been defined to reduce the 
bandwidth requirements of the emulated SONET/SDH circuits under 
certain conditions. These OPTIONAL formats are included in 

Section 11. 


5.2. CEP Header 


The CEP header supports both a basic and extended mode. The Basic 
CEP header provides the minimum functionality necessary to accurately 
emulate a SONET/SDH circuit over a PSN. Extended headers are 
utilized for some of the OPTIONAL SONET/SDH fragment formats 
described in Section 11. 


Enhanced functionality and commonality with other real-time Internet 
applications is provided by RTP encapsulation. 
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The CEP header has the following format: 


0 1 2 3 
00:12:34, 3:16 1-8 90D 234 56 FBO Or de 2.304 96: 8. 9 OL 
A A O + dh dd tata tata tata + + tata tata ta +++ +++ ++ ++ 
ojololo|L|rR|N|P|rRG|Length[0:5]| Sequence Number[0:15] | 
dh + Ph q e hd + + + q + hh + + ho ++ 
Reserved |structure Pointer[0:11]| 
dh + Ph q hd + + + + + + + ++ hh + ++ +++ +++ ++ 


Figure 2: CEP Header Format 


L bit: CEP-AIS. This bit MUST be set to 1 to signal to the 
downstream PE that a failure condition has been detected on the 
attachment circuit. Failure conditions leading to generation of 
CEP-AIS and the mapping of CEP-AIS signal on the downstream 
attachment circuit are described in Section 7. 


R bit: CEP-RDI. This bit MUST be set to 1 to signal to the upstream 
PE that a loss of packet synchronization has occurred. This bit 
MUST be set to 0 once packet synchronization is acquired. See 
Section 6.2 for details. 


N and P bits: These bits are used to explicitly relay negative and 
positive pointer adjustments events across the PSN. The use of N 
and P bits is OPTIONAL. If not used, N and P bits MUST be set to 
0. See Section 9 for details. 


Table 2 describes the interpretation of N and P bits settings. 


No Pointer Adjustments 
Positive Pointer Adjustment 
Negative Pointer Adjustment | 
Loss of Pointer Alarm | 


Table 2: Interpretation of N and P Bits 


FRG bits: FRG bits MUST be set to 0 by sender and ignored by 
receiver. 


SONET data is continuously fragmented into packets. The structure 


pointer field designates the offset between the SONET SPE or VT 
structure and the packet boundary. 
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Length [0:5]: The Length field, if other than zero, indicates the 
length of the CEP header, plus the length of the RTP header if 
used, plus the length of the payload. The Length field MUST be 
set if the length of CEP header plus RIP header if used, plus 
payload is less than or equal to 64 bytes and MUST be set to 0 
otherwise. In particular, if the payload is suppressed (e.g., 
DBA) the Length field MUST be set to the CEP header length plus 
the RTP header length if used. 


Sequence Number [0:15]: The packet sequence number MUST continuously 
cycle from 0 to OxFFFF. It is generated and processed in 
accordance with the rules established in [RTP]. 


Structure Pointer [0:11]: The structure pointer MUST contain the 
offset of the first byte of the SONET structure within the packet 
payload. For SPE emulation, the structure pointer locates the Jl 
byte within the CEP packet. For VT emulation, the structure 
pointer locates the V5 byte within the packet. The structure 
pointer value ranges between 0 to OxFFE, where 0 represents the 
first byte after the CEP header. The structure pointer MUST be 
set to OxFFF if a packet does not carry the J1 (or V5) byte. An 
arbitrary pointer change (New Data Flag (NDF) event) in the 
attachment circuit changes the offset of the SONET structure 
within the CEP packet and therefore changes the structure pointer 
value. 


Reserved field: The reserved field MUST be set to 0 by the sender 
and ignored by receiver. 


5.3. RIP Header 


Usage of the RTP header is OPTIONAL. Although CEP MAY employ an RTP 
header when explicit transfer of timing information is required, this 
is purely a formal reuse of the header format. RTP mechanisms, such 
as header extensions, contributing source (CSRC) list, padding, RTP 
Control Protocol (RTCP), RTP header compression, Secure Realtime 
Transport Protocol (SRTP), etc., are not applicable to pseudowires. 
CEP uses the RTP Header as shown below. 
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0 1 2 3 
0.1 2° 3:45 6:-7:8:90.1.234 5.67 8901:2345:6 789041 
a a a E E E 

|v=2|P|x| cc |m] PT | Sequence Number 
a a tat arta ta tata tata tat a tata tata tata tata tata tata E 
| Timestamp | 
Pat RFF rt R A S A a A T E S E S E a E 
| Synchronization Source (SSRC) Identifier 

eE a a a a a a a a a a E E ai 


Figure 3: RTP Header 
V: Version. The Version field MUST be set to 2. 


P: Padding. No padding is required. The P bit MUST be set to 0 by 
sender and ignored by receiver. 


X: Header extension. No extensions are defined. The X bit MUST be 
set to 0 by sender and ignored by receiver. 


CC: CSRC count. The CC field MUST be set to 0 by sender and ignored 
by receiver. 


M: Marker. The M bit MUST be set to 0 by sender and ignored by 
receiver. 


PT [0:6]: Payload type. A PT value SHOULD be allocated from the 
range of dynamic values for each direction of the PW. The same PT 
value MAY be reused both for direction and between different CEP 


PWs. 

Sequence Number [0:15]: The packet sequence number MUST continuously 
cycle from 0 to OxFFFF. It is generated and processed in 
accordance with the rules established in [RTP]. The CEP receiver 


MUST sequence packets according to the Sequence Number field of 
the CEP header and MAY verify correct sequencing using RTP 
Sequence Number field. 


Timestamp [0:31]: Timestamp values are used in accordance with the 
rules established in [RTP]. Frequency of the clock used for 
generating timestamps MUST be 19.44 MHz based on a local 
reference. 


SSRC [0:31]: Synchronization source. The SSRC field MAY be used for 
detection of misconnections. 
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5.4. PSN Encapsulation 


This document defines the transport of CEP over MPLS PSNs. The 
bottom label in the MPLS label stack MUST be used to de-multiplex 
individual CEP channels. In keeping with the conventions used in 
[PWE3-CONTROL], this de-multiplexing label is referred to as the PW 
Label and the upper labels are referred to as Tunnel Labels. The CEP 
header follows the generic PWE3 Control Word format specified in 
[PWE3-MPLSCW] for use over an MPLS PSN. 


Transport of CEP over other PSN technologies is out of scope of this 
document. 


6. CEP Operation 


A CEP implementation MUST support a normal mode of operation and MAY 
support additional bandwidth conserving modes as described in 
Section 11. During normal operation, SONET/SDH payloads are 
fragmented, prepended with the appropriate headers, and then 
transmitted into the packet network. 


6.1. CEP Packetizer and De-Packetizer 


As with all adaptation functions, CEP has two distinct components: 
adapting TDM SONET/SDH into a CEP packet stream, and converting the 
CEP packet stream back into a TDM SONET/SDH. The first function is 
referred to as CEP packetizer or sender and the second as CEP de- 
packetizer or receiver. This terminology is illustrated below. 


$ == + $2 + 
| | | | 
SONET --> | CEP | --> PSN --> | CEP | --> SONET 
SDH | Packetizer | | De-Packetizer | SDH 
| | | | 
$ + a + 
(sender) (receiver) 


Figure 4: CEP Terminology 


The CEP de-packetizer requires a buffering mechanism to account for 
delay variation in the CEP packet stream. This buffering mechanism 
is generically referred to as the CEP jitter buffer. 


During normal operation, the CEP packetizer receives a fixed-rate 
byte stream from a SONET/SDH interface. When a packet worth of data 
is received from a SONET/SDH channel, the necessary headers are 
prepended to the SPE fragment and the resulting CEP packet is 
transmitted into the packet network. Because all CEP packets 
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associated with a specific SONET/SDH channel have the same length, 
the transmission of CEP packets for that channel SHOULD occur at 
regular intervals. 


At the far end of the packet network, the CEP de-packetizer receives 
packets into a jitter buffer and then plays out the received byte 
stream at a fixed rate onto the corresponding SONET/SDH channel. The 
jitter buffer SHOULD be adjustable in length to account for varying 
network delay behavior. On average, the receive packet rate from the 
packet network should be balanced by the transmission rate onto the 
SONET/SDH channel. 


The CEP sequence numbers provide a mechanism to detect lost and/or 
misordered packets. The sequence number in the CEP header MUST be 
used when transmission of the RTP header is suppressed. The CEP de- 
packetizer MUST detect lost or misordered packets. The CEP de- 
packetizer SHOULD play out an all-ones pattern (AIS) in place of any 
dropped packets. The CEP de-packetizer SHOULD re-order packets 
received out of order. If the CEP de-packetizer does not support re- 
ordering, it MUST drop misordered packets. 


6.2. Packet Synchronization 


A key component in declaring the state of a CEP service is whether or 
not the CEP de-packetizer is in or out of packet synchronization. 
The following paragraphs describe how that determination is made. 


As packets are received from the PSN, they are placed into a jitter 
buffer prior to play out on the SONET/SDH interface. If a CEP de- 
packetizer supports re-ordering, any packet received before its play 
out time will still be considered valid. 


The determination of acquisition or loss of packet synchronization is 
always made at SONET/SDH play out time. During SONET/SDH play out, 
the CEP de-packetizer will play received CEP packets onto the SONET/ 
SDH interface. However, if the jitter buffer is empty or the packet 
to be played out has not been received, the CEP de-packetizer will 
play out an ’empty packet’ composed of an all-ones AIS pattern onto 
the SONET/SDH interface in place of the unavailable packet. 


The acquisition of packet synchronization is based on the number of 
sequential CEP packets that are played onto the SONET/SDH interface. 
Loss of packet synchronization is based on the number of sequential 
‘empty’ packets that are played onto the SONET/SDH interface. 
Specific details of these two cases are described below. 


Malis, et al. Standards Track [Page 12] 


RFC 4842 SONET/SDH Circuit Emulation April 2007 


6.2.1. Acquisition of Packet Synchronization 


At startup, a CEP de-packetizer will be out of packet synchronization 
by default. To declare packet synchronization at startup or after a 
loss of packet synchronization, the CEP de-packetizer must play out a 
configurable number of CEP packets with sequential sequence numbers 
towards the SONET/SDH interface. 


Os 22s Loss of Packet Synchronization 
Once a CEP de-packetizer is in packet synchronization state, it may 


encounter a set of events that will cause it to lose packet 
synchronization. 


If the CEP de-packetizer encounters more than a configurable number 
of sequential empty packets, the CEP de-packetizer MUST declare a 
Loss of Packet Synchronization (LOPS) defect. 


LOPS failure is declared after 2.5 +/- 0.5 seconds of LOPS defect, 
and cleared after 10 seconds free of LOPS defect state. The circuit 
is considered down as long as LOPS failure is declared. 


7. SONET/SDH Maintenance Signals 


This section describes the mapping of maintenance and alarm signals 
between the SONET/SDH network and the CEP pseudowire. For clarity, 
the mappings are split into two groups: SONET/SDH to PSN, and PSN to 
SONET/SDH. 


For coherent failure detection, isolation, monitoring, and 
troubleshooting, SONET/SDH failure indications MUST be transferred 
correctly over the CEP pseudowire, and CEP connection failures MUST 
be mapped to SONET/SDH SPE/VT failure indications. Failure detection 
capabilities and performance monitoring capabilities are dependent on 
the NSP functionality, e.g., LTE, PTE, Tandem Connection Monitoring 
[G.707], or Non-intrusive Monitoring (intermediate connection 
monitoring). 


7.1. SONET/SDH to PSN 


The following sections describe the mapping of SONET/SDH Maintenance 
Signals and Alarm conditions into CEP pseudowire indications. 


7.1.1.  CEP-AIS: AIS-P/V Indication 
SONET/SDH Path outages are signaled by using maintenance alarms such 


as Path AIS (AIS-P). AIS-P, in particular, indicates that the SONET/ 
SDH Path is not currently transmitting valid end-user data, and the 
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SPE contains all ones. Similarly, AIS-V indicates that the VT is not 
currently transmitting valid end-user data, and the VT contains all 
ones. 


It should be noted that nearly every type of service-affecting 
section or line defect would result in an AIS-P/V condition. 


The mapping of SONET/SDH failures into the SPE/VT layer is considered 
part of the NSP function and is based on the principles specified in 
[GR253], [SONET], [G.707], [G.806], and [G.783]. For example, should 
the SONET Section Layer detect a Loss of Signal (LOS) or Loss of 
Frame (LOF) or Section Trace Mismatch (TIM) conditions, an AIS-L is 
sent up to the Line Layer. If the Line Layer detects AIS-L or Loss 
of Pointer (LOP), an AIS-P is sent to the Path Layer. If the Path is 
terminated at the PE (i.e., a PTE) and the Path Layer detects AIS-P 
or UNEQ-P or TIM-P or PLM-P an AIS-V is sent to the VT Layer. 


The AIS-P/V indication is transferred to the CEP packetizer. During 
AIS-P/V, CEP packets are generated as usual. The L bit in the CEP 
header MUST be set to 1 to signal AIS-P/V explicitly through the 
packet network. The N and P bits SHOULD be set to 1 to indicate loss 
of pointer indication. 


If DBA has been enabled for AIS-P/V, only the necessary headers and 
optional padding are transmitted into the packet network. The Length 
field MUST be set to the size of the CEP header plus the size of the 
RTP header if used. 


7.1.2. Unequipped Indication 


Unequipped indication is used for bandwidth conserving modes defined 
in Section 11 as a trigger for payload removal. 


The declaration of the SPE/VT channel as Unequipped MUST conform to 
[GR253], [SONET], [G.806], and [G.783]. Unequipped circuits do not 
carry valid end-user data, but MAY be used for transporting valid 
information in the SPE/VT overhead bytes. Supervisory Unequipped 
signals and Tandem Connection transport are two such applications: 


Supervisory Unequipped signal (called TEST-P in [SONET]) is used 
to provide a test signal for pre-service testing or in-service 
supervision of a path connection to a remote PTE from a PTE or an 
intermediate non-terminating path network element. Both 
Unequipped and Supervisory Unequipped signals carry Unequipped 
Signal Label defined to be zero. To distinguish between 
Unequipped and Supervisory Unequipped signals, [G.806] recommends 
that the SPE/VT Trace bytes J1/J2 be set to a non-zero value in 
Supervisory Unequipped signals. 
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The SPE/VT overhead bytes N1/Z6 (SDH refers to Z6 as N2) 
optionally transport Tandem Connection signals between 
intermediate network elements. Unequipped signals transporting 
Tandem Connection would have non-zero N1 or N2/Z6 bytes. 


Therefore, the CEP packetizer MUST declare a circuit unequipped only 
if the Signal Label, Trace (J1/J2), and Tandem Connection (N1/N2/Z6) 
bytes all have zero value. 


During SPE/VT Unequipped, the N and P bits MUST be interpreted as 
usual. The SPE/VT MUST be transmitted into the packet network along 
with the appropriate headers. 


If DBA has been enabled for Unequipped SPE/VT, only the necessary 
headers and optional padding are transmitted into the packet network. 
The Length field MUST be set to the size of the CEP header plus the 
size of the RTP header if used. The N and P bits MAY be used to 
signal pointer adjustments as normal. 


7.1.3. CEP-RDI: Remote Defect Indication 


The CEP function MUST send CEP-RDI indication towards the packet 
network during loss of packet synchronization by setting the R bit to 
one in the CEP header. The CEP function SHOULD clear the R bit once 
packet synchronization is restored. 


7.2. PSN to SONET/SDH 


The following sections describe the mapping of pseudowire indications 
to SONET/SDH Maintenance Signals and Alarm conditions. 


7.2.1. CEP-AIS: AIS-P/V Indication 


There are several conditions in the packet network that cause the CEP 
de-packetization function to play out an AIS-P/V indication towards a 
SONET/SDH channel. The CEP de-packetizer MUST play out one packet's 
worth of all ones for each packet received, and MUST set the SONET/ 
SDH Overhead to signal AIS-P/V as defined in [SONET], [GR253], and 
[G.707]. 


The first of these is the receipt of CEP packets with the L bit set 
to one indicating that the far end has detected an error leading to 
declaration of AIS-P/V alarm. In addition to the play out of 
AIS-P/V, the CEP de-packetizer SHOULD set the pointer value to all- 
ones value. 
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The second case that will cause a CEP de-packetization function to 
play out an AIS-P/V indication onto a SONET/SDH channel is during 
loss of packet synchronization. 


The third case is the receipt of CEP packets with both the N and P 
bits set to 1. This is an explicit indication of Loss of Pointer 
LOP-P/V received at the far-end of the packet network. In addition 
to play out of AIS-P/V, the CEP de-packetizer SHOULD set the pointer 
value to all-ones value. 


7.2.2. Unequipped Indication 


There are several conditions in the packet network that cause the CEP 
function to transmit Unequipped indications onto the SONET/SDH 
channel. 


The first, which is transparent to CEP, is the receipt of regular CEP 
packets that happen to carry an SPE/VT containing the appropriate 
Path overhead or VT overhead set to Unequipped. This case does not 
require any special processing on the part of the CEP de-packetizer. 


The second case is the receipt of CEP packets with the Length field 
indicating that the payload was removed by DBA, while the L bit is 
set to 0, indicating that the DBA was triggered by an Unequipped 
indication and not by an AIS-P/V indication. The CEP de-packetizer 
MUST use this information to transmit a packet of all zeros onto the 
SONET/SDH interface. 


The third case when a CEP de-packetizer MUST play out an SPE/VT 
Unequipped indication towards the SONET/SDH interface is when the 
circuit has been de-provisioned. 


8. SONET/SDH Transport Timing 


It is assumed that the distribution of SONET/SDH transport timing 
information is addressed either through external mechanisms such as 
Building Integrated Timing Supply (BITS), Stand Alone Synchronization 
Equipment (SASE), Global Positioning System (GPS), or other such 
methods, or is obtained through an adaptive timing recovery 
mechanism. 


Details about specific adaptive algorithms for recovery of SONET/SDH 
transport timing are not considered to be within scope for this 


document. The wander and jitter limits for networks based on the SDH 
hierarchy are defined in [G.825] and for the SONET hierarchy in 
[GR253]. The wander and jitter limits specified in these standards 


must be maintained when CEP PWs are used. 
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SONET/SDH Pointer Management 


A pointer management system is defined as part of the definition of 
SONET/SDH. Details on SONET/SDH pointer management can be found in 
[SONET], [GR253], [G.707], and [G.783]. If there is a frequency 
offset between the frame rate of the transport overhead and that of 
the SONET/SDH SPE, the alignment of the SPE will periodically slip 
back or advance in time through positive or negative stuffing. 
Similarly, if there is a frequency offset between the SPE rate and 
the VT rate it carries, the alignment of the VT will periodically 
slip back or advance in time through positive or negative stuffing 
within the SPE. 


The emulation of this aspect of SONET/SDH networks may be 
accomplished using a variety of techniques including Explicit Pointer 
Adjustment Relay (EPAR) and Adaptive Pointer Management (APM). 


In any case, the handling of the SPE or VT data by the CEP packetizer 
is the same. 


During a negative pointer adjustment event, the CEP packetizer MUST 
incorporate the H3 (or V3) byte from the SONET/SDH stream into the 
CEP packet payload in order with the rest of the SPE (or VT). During 
a positive pointer adjustment event, the CEP packetizer MUST strip 
the stuff byte from the CEP packet payload. 


When playing out a negative pointer adjustment event, the appropriate 
byte of the CEP payload MUST be placed into the H3 (or V3) byte of 
the SONET/SDH stream. When playing out a positive pointer 
adjustment, the CEP de-packetizer MUST insert a stuff byte into the 
appropriate position within the SONET/SDH stream. 


The details regarding the use of the H3 (and V3) byte and stuff byte 
during positive and negative pointer adjustments can be found in 
[SONET], [GR253], and [G.707]. 


Explicit Pointer Adjustment Relay (EPAR) 


CEP provides an OPTIONAL mechanism to explicitly relay pointer 
adjustment events from one side of the PSN to the other. This 
technique is referred to as Explicit Pointer Adjustment Relay (EPAR). 
EPAR is only effective when both ends of the PW have access to a 
common timing reference. 


The following text only applies to CEP implementations that choose to 
implement EPAR. Any CEP implementation that does not support EPAR 
MUST set the N and P bits to 0. 
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The pointer adjustment event MUST be transmitted in three consecutive 
packets by the packetizer. The de-packetizer MUST play out the 
pointer adjustment event when any one packet with N/P bit set is 
received. The CEP de-packetizer MUST utilize the CEP sequence 
numbers to ensure that SONET/SDH pointer adjustment events are not 
played any more frequently than once per every three CEP packets 
transmitted by the remote CEP packetizer. 


The VT EPAR packetizer MUST relay pointer adjustment indications 
received at the SPE level in addition to relaying VT pointer 
adjustment indications. Because of the rate differences between VT 
and SPE, the magnitude of a VT pointer adjustment is much larger than 
that of an SPE adjustment. Therefore, the VT EPAR packetizer has to 
convert multiple SPE pointer adjustments to fewer VT pointer 
adjustment indications signaled over the PSN using the N and P CEP 
header bits. A simple algorithm can be used for this purpose using 
an accumulator (counter): 


The accumulator value is reset to 0 when the circuit is in Loss of 
Packet Synchronization (LOPS) state. 


A positive pointer adjustment indication increases the accumulator 
value by a fixed quota, while negative pointer adjustment 
subtracts the same quota from the accumulator. A VT pointer 
adjustment changes the accumulator value by 783 units (one STS-1 
SPE size). An SPE pointer adjustment changes the accumulator 
value by quota that depends on the VT emulation type. The quota 
is 1/4 of the VT size as defined in Table 1, e.g., 26 bytes for 
VT1.5 emulation and 35 bytes for VT2 emulation. 


When the accumulator value is larger than or equal to 783 units, a 
positive pointer adjustment is signaled towards the PSN using the 
CEP header P bit and 783 units are subtracted from the 
accumulator. 


When the accumulator value is smaller than or equal to minus 783 
units, a negative pointer adjustment is signaled towards the PSN 
using the CEP header N bit and 783 units are added to the 
accumulator. 


The same algorithm is applicable for SDH Virtual Container carried in 
VC-4, i.e., positive VC-4 pointer adjustment adds 35 units to a VC-12 
accumulator, while positive VC-12 pointer adjustment adds 783 units 
to the accumulator. 
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If both N and P bits are set, then a Loss of Pointer event has been 
detected at the PW ingress, making the pointer invalid. The de- 
packetizer MUST play out an AIS-P/V indication and SHOULD set the 
pointer value to all-ones value. 


9.2. Adaptive Pointer Management (APM) 


Another OPTIONAL method that may be used to emulate SONET/SDH pointer 
management is Adaptive Pointer Management (APM). In basic terms, APM 
uses information about the depth of the CEP jitter buffers to 
introduce pointer adjustments in the reassembled SONET/SDH SPE. 


Details about specific APM algorithms are not considered to be within 
scope for this document. 


10. CEP Performance Monitors 


SONET/SDH as defined in [SONET], [GR253], [G.707], and [G.784] 
includes a definition of several counters used to monitor the 
performance of SONET/SDH services. These counters are referred to as 
Performance Monitors. 


In order for CEP to be utilized by traditional SONET/SDH network 
operators, CEP SHOULD provide similar functionality. The following 
sections describe a number of counters that are collectively referred 
to as CEP Performance Monitors. 


10.1. Near-End Performance Monitors 


These performance monitors are maintained by the CEP de-packetizer 
during reassembly of the SONET/SDH stream. 


The performance monitors are based on two types of defects. 
Type 1: missing or dropped packet. 


Type 2: buffer underrun, buffer overrun, LOPS, missing packets 
above predefined configurable threshold. 


The specific performance monitors defined for CEP are as follows: 


ES-CEP - CEP Errored Seconds 
SES-CEP - CEP Severely Errored Seconds 
UAS-CEP - CEP Unavailable Seconds 
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11. 


Each second that contains at least one type 1 defect SHALL be 
declared as ES-CEP. Each second that contains at least one type 2 
defect SHALL be declared as SES-CEP. 


UAS-CEP SHALL be declared after configurable number of consecutive 
SES-CEP, and cleared after a configurable number of consecutive 
seconds without SES-CEP. Default value for each is 10 seconds. 


Once unavailability is declared, ES and SES counts SHALL be inhibited 
up to the point where the unavailability was started. Once 
unavailability is removed, ES and SES that occurred along the 
clearing period SHALL be added to the ES and SES counts. 


CEP-NE failure is declared after 2.5 +/- 0.5 seconds of CEP-NE type 2 
defect, and cleared after 10 seconds free of CEP-NE defect state. 
Sending notification to the OS for CEP-NE failure is local policy. 


.2. Far-End Performance Monitors 


Far-end performance monitors provide insight into the CEP de- 
packetizer at the far end of the PSN. 


Far-end statistics are based on the CEP-RDI indication carried in the 
CEP header R bit. CEP-FE defect is declared when CEP-RDI is set in 
the incoming CEP packets. 


CEP-FE failure is declared after 2.5 +/- 0.5 seconds of CEP-FE 
defect, and cleared after 10 seconds free of CEP-FE defect state. 
Sending notification to the OS for CEP-FE failure is local policy. 


Payload Compression Options 


In addition to pure emulation, CEP also offers a number of options 
for reducing the total bandwidth utilized by the emulated circuit. 
These options fall into two categories: Dynamic Bandwidth Allocation 
(DBA) and Service-Specific Payload Formats. 


DBA suppresses transmission of the CEP payload altogether under 
certain circumstances such as AIS-P/V and SPE/VT Unequipped. The use 
of DBA is dependent on network architectures, e.g., support of Tandem 
Connection Monitoring, test signals (TEST-P) [SONET], or Supervisory 
Unequipped [G.806] signals. 


Service-Specific Payload Formats reduce bandwidth by suppressing 
transmission of portions of the SPE based on specific knowledge of 
the SPE payload. 
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Details on these payload compression options are described in the 
following subsections. 


11.1. Dynamic Bandwidth Allocation 


Dynamic Bandwidth Allocation (DBA) is an OPTIONAL mechanism for 
suppressing the transmission of the SPE (or VT) fragment when one of 
two trigger conditions are met, AIS-P/V or SPE/VT Unequipped. 


Implementations that support DBA MUST include a mechanism for 
disabling DBA on a channel-by-channel basis to allow for 
interoperability with implementations that do not support DBA. 


When a DBA trigger is recognized at PW ingress, the CEP payload will 
be suppressed. The CEP Length field MUST be set to the CEP header 
length plus the RTP header length if used, and padding bytes SHOULD 
be added if the intervening packet network has a minimum packet size 
that is larger than the payload-suppressed DBA packet. 


Other than the suppression of the CEP payload, the CEP behavior 
during DBA should be equivalent to normal CEP behavior. In 
particular, the packet transmission rate during DBA should be 
equivalent to the normal packet transmission rate. 


11.2. Service-Specific Payload Formats 


In addition to the standard payload encapsulations for SPE and VT 
transport, several OPTIONAL payload formats have been defined to 
provide varying amounts of payload compression depending on the type 
and amount of user traffic present within the SPE. These are 
described below. 


11.2.1. Fractional STS-1 (VC-3) Encapsulation 


Fractional STS-1 (VC-3) encapsulation carries only a selected set of 
VTs within an STS-1 container. This mode is applicable for STS-1 
with POH signal label byte C2=2 (VI-structured SPE) and for C2=3 
(Locked VT mode). 


Implementations of fractional STS-1 (VC-3) encapsulation MUST support 
payload length of one SPE and MAY support payload length of 1/3 SPE. 


The mapping of VTs into an STS-1 container is described in Section 
3.2.4 of [GR253], and the mapping into VC-3 is defined in Section 
7.2.4 in [G.707]. The CEP packetizer removes all fixed column bytes 
(columns 30 and 59) and all bytes belonging to the removed VTs. Only 
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STS-1 POH bytes and bytes that belong to the selected VTs are carried 
within the payload. The CEP de-packetizer adds the fixed stuff bytes 
and generates unequipped VT data replacing the removed VT bytes. 


The figure below illustrates VT1.5 mapping into an STS-1 SPE. 


1 2 3. EH 29: 30.31 32 ELE 898. 99. 60. Ol F A By 


+--+------------------ HH +-+------------------ + 
1 |o1] Byte 1 wi-vay [RI | | | iri || || 
+--+---+---+------ $---4-4------------------ HH + 
2 |B3|vr | | po {Rl | | | {Rl | Ml 
+--41.5| | | +-+---+---+------ +---+-+------------------ + 
3 |ce2] | | ; {Rl | | eee A Fee | | 
+--+ | | | +-+---+---+------ +---+-+------------------ + 
4 [e] ||] (ORE | | [ORE [O Me otf 
+--+ | | | +-+---+---+------ +---+-+------------------ + 
5 |F2| R) o] {| [ro | | 
+--|1-1]2-1] * * *|7-4]-|1-1]2-1] * * *|7-4]-|1-1]2-1] * * *|7-4| 
6 [aa] | | po {IR} | | LORE A | | 
+--+ | | | +-+---+---+------ +---+-+------------------ + 
7 (23, || (ORE | | | {Rl || | | 
+--+ | | | +-+---+---+------ +---+-+-----------------—- + 
e |z4| IR] |] | Ar | Mesa 
+--+ | | | +-+---+---+------ $ A A + 
9 zs) | | | dr] |] | RE |] | | 
+--+---+---+------ +---+-+---+---+------ +---+-+---------------- + 
| | 
+-- Path Overhead as al aia E +-- Fixed Stuffs 


Figure 5: SONET SPE Mapping of VT1.5 


The SPE always contains seven interleaved VT groups (VIGs). Each VIG 
contains a single type of VI, and each VIG occupies 12 columns (108 
bytes) within each SPE. A VTG can contain 4 VT1.5s (Tls), 3 VT2s 
(Els), 2 VI3s, or a single VT6. Altogether, the SPE can carry 28 Tls 
or carry 21 Els. 


The fractional STS-1 encapsulation can optionally carry a bit mask 
that specifies which VTs are carried within the STS-1 payload and 
which VTs have been removed. This optional bit mask attribute allows 
the ingress circuit emulation node to remove an unequipped VT on the 
fly, providing the egress circuit emulation node enough information 
for reconstructing the VTs in the right order. The use of bit mask 
enables on-the-fly compression, whereby only equipped VTs (carrying 
actual data) are sent. 
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11.2.1.1. Fractional STS-1 CEP Header 


The fractional STS-1 CEP header uses the STS-1 CEP header 
encapsulation as defined in this document. Optionally, an additional 
4-byte header extension word is added. 


The extended header has the following format: 


0 1 2 3 

OF 2 034 Or Tg 9-081) 23) Ala 678) 9000 2034: 976.01 89 20e 1 
toto + Ph q tata tata tata tata ta + + + + hh + ++ ++ + +++ ++ 
|o|o|o|o|L|R|N|P|FRG|Length[0:5] | Sequence Number[0:15] | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ hh + ++ ++ ++ += +++ 
| Reserved |Structure Pointer[0:11] | 
+ 
: 


Stata tartar ta tata ta tarda ta tata ta tata ta tata tata tata E O E 
Equipped Bit Mask (EBM) [0:27] 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


o 
+— + 
o 
+—+ 
©) 
+—+ 
o 
++ 


Figure 6: Extended Fractional STS-1 Header 


The L, R, N, P, FRG, Length, Sequence Number, and Structured Pointer 
fields are used as defined in this document for STS-1 encapsulation. 


Each bit within the Equipped Bit Mask (EBM) field refers to a 
different VT within the STS-1 container. A bit set to 1 indicates 
that the corresponding VI is equipped, hence carried within the 
fractional STS-1 payload. 


The STS-1 EBM has the following format: 


0 1 2 

O 1-2 34.5 6°54. 289: 001 :2 34 961. 8:09:01: 2.3.4 “5:66, 7 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| VTG7 | vTG6 | vre5 | vIG4 | vre3 | vre2 | vrei | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 7: Equipped Bit Mask (EBM) for Fractional STS-1 


The 28 bits of the EBM are divided into groups of 4 bits, each 
corresponding to a different VTG within the STS container. All 4 
bits are used to indicate whether VT1.5 (T1) tributaries are carried 
within a VTG. The first 3 bits read from right to left are used to 
indicate whether VT2 (El) tributaries are carried within a VTG. The 
first 2 bits are used to indicate whether VT3 (DS1C) tributaries are 
carried within a VTG. The rightmost bit is used to indicate whether 
a VT6 (DS2) is carried within the VTG. The VTs within the VTG are 
numbered from right to left, starting from the first VT as the first 
bit on the right. For example, the EBM of a fully occupied STS-1 
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with VT1.5 tributaries is all ones, while that of an STS-1 fully 
occupied with VT2 (El) tributaries has the binary value 
0111011101110111011101110111. 


.2.1.2. B3 Compensation 


Fractional STS-1 encapsulation can be implemented in Line Terminating 
Equipment (LTE) or in Path Terminating Equipment (PTE). PTE 
implementations terminate the path layer at the ingress PE and 
generate a new path layer at the egress PE. 


LTE implementations do not terminate the path layer, and therefore 
need to keep the content and integrity of the POH bytes across the 
PSN. In LTE implementations, special care must be taken to maintain 
the B3 bit-wise parity POH byte. The B3 compensation algorithm is 
defined below. 


Since the BIP-8 value in a given frame reflects the parity check over 
the previous frame, the changes made to BIP-8 bits in the previous 
frame shall also be considered in the compensation of BIP-8 in the 
current frame. Therefore, the following equation shall be used for 
compensation of the individual bits of the BIP-8: 


B3[il’ (t) = B3[i] (t-1) || B3[i]’ (t-1) || B3[i](t) || B*3[1] (t-1) 
Where: 
B3 [i] = the existing B3[i] value in the incoming signal 
B3[i]’ = the new (compensated) B3[i] value 
B3*[i] = the B3[i] value of the unequipped VTs in the 


incoming signal 
| | = exclusive OR operator 
È = the time of the current frame 
t-1 = the time of the previous frame 


The egress PE MUST reconstruct the unequipped VTs and modify the B3 
parity value in the same manner to accommodate the additional VTs 
added. In this way, the end-to-end BIP is preserved. 


.2.1.3. Actual Payload Size 


The actual CEP payload size depends on the number of virtual 
tributaries carried within the fractional SPE. The contributions of 
each tributary to the fractional STS-1 payload size as well as the 
path overhead contribution are described below. 


Each VT1.5 contributes 27 bytes 


Malis, et al. Standards Track [Page 24] 


RFC 4842 SONET/SDH Circuit Emulation April 2007 


Each VT2 contributes 36 bytes 
Each VT3 contributes 54 bytes 
Each VT6 contributes 108 bytes 
STS-1 POH contributes 9 bytes 


For example, a fractional STS-1 carrying 7 VT2 circuit in full-SPE 
encapsulation would have an actual size of 261=36*7+9 bytes. Divide 
by 3 to calculate the third-SPE encapsulation actual payload sizes. 


11.2.2. Asynchronous T3/E3 STS-1 (VC-3) Encapsulation 


Asynchronous T3/E3 STS-1 (VC-3) encapsulation is applicable for 
signals with POH signal label byte C2=4, carrying asynchronously 
mapped T3 or E3 signals. 


Implementations of asynchronous T3/E3 STS-1 (VC-3) encapsulation MUST 
support payload length of one SPE and MAY support payload length of 
1/3 SPE. 


11.2.2.1. T3 Payload Compression 


A T3 is encapsulated asynchronously into an STS-1 SPE using the 
format defined in Section 3.4.2.1 of [GR253]. The STS-1 SPE is then 
encapsulated as defined in this document. 


Optionally, the STS-1 SPE can be compressed by removing the fixed 
columns leaving only data columns. STS-1 columns are numbered 1 to 
87, starting from the POH column numbered 1. The following columns 
have fixed values and are removed: 2, 3, 30, 31, 59, and 60. 


Bandwidth saving is approximately 7% (6 columns out of 87). The B3 
parity byte need not be modified as the parity of the fixed columns 
amounts to 0. The actual payload size for full-SPE encapsulation 
would be 729 bytes and 243 bytes for third-SPE encapsulation. 


A T3 is encapsulated asynchronously into a VC-3 container as 
described in Section 10.1.2.1 of [G.707]. VC-3 container has only 85 
data columns, which is identical to the STS-1 container with the two 
fixed stuff columns 30 and 59 removed. Other than that, the mapping 
is identical. 
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11.2.2.2. E3 Payload Compression 


An E3 is encapsulated asynchronously into a VC-3 SPE using the format 
defined in Section 10.1.2.2 of [G.707]. The VC-3 SPE is then 
encapsulated as defined in this document. 


Optionally, the VC-3 SPE can be compressed by removing the fixed 
columns leaving only data columns. VC-3 columns are numbered 1 to 85 
(and not 87), starting from the POH column numbered 1. The following 
columns have fixed values and are removed: 2, 6, 10, 14, 18, 19, 23, 
27, 31, 35, 39, 44, 48, 52, 56, 60, 61, 65, 69, 73, 77, and 81. 


Bandwidth saving is approximately 28% (24 columns out of 85). The B3 
parity byte need not be modified as the parity of the fixed columns 
amounts to 0. The actual payload size for full-SPE encapsulation 
would be 567 bytes and 189 bytes for third-SPE encapsulation. 


11.2.3. Fractional VC-4 Encapsulation 
SDH defines a mapping of VC-11, VC-12, VC-2, and VC-3 directly into 


VC-4. This mapping does not have an equivalent within the SONET 
hierarchy. The VC-4 mapping is common in SDH implementations. 


VC-4 <--x3-- TUG-3 <-------- x1-------- TU-3 <-- VC-3 <---- E3/T3 
Hee TUG-2 <--x1-- TU-2 <-- vc-2 <---- DS2 
isis TU-12 <-- VC-12<---- El 
isos TU-11 <-- VC-11<---- T1 


Figure 8: Mapping of VCs into VC-4 


Figure 8 describes the mapping options of VCs into VC-4. A VC-4 
contains three TUG-3s. Each TUG-3 is composed of either a single 
TU-3 or 7 TUG-2s. A TU-3 contains a single VC-3. A TUG-2 contains 
either 4 VC-11s (Tls), 3 VC-12s (Els), or one VC-2. Therefore, a 
VC-4 may contain 3 VC-3s, 1 VC-3 and 42 VC-12s, 63 VC-12s, etc. 


Fractional VC-4 encapsulation carries only a selected set of VCs 
within a VC-4 container. This mode is applicable for VC-4 with POH 
signal label byte C2=2 (TUG structure) and for C2=3 (Locked TU-n). 
The mapping of VCs into a VC-4 container is described in Section 7.2 
of [G.707]. The CEP packetizer removes all fixed column bytes and 
all bytes that belong to the removed VCs. Only VC-4 POH bytes and 
bytes that belong to the selected VCs are carried within the payload. 
The CEP de-packetizer adds the fixed stuff bytes and generates 
unequipped VC data replacing the removed VC bytes. 
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The fractional VC-4 encapsulation can optionally carry a bit mask 
that specifies which VCs are carried within the VC-4 payload and 
which VCs have been removed. This optional bit mask attribute allows 
the ingress circuit emulation node to remove unequipped VCs on the 
fly, providing the egress circuit emulation node enough information 
for reconstructing the VCs in the right order. The use of bit mask 
enables on-the-fly compression, whereby only equipped VCs (carrying 
actual data) are sent. 


VC-3 carrying asynchronous T3/E3 signals within the VC-4 container 
can optionally be compressed by removing the fixed column bytes as 
described in Section 11.2.2, providing additional bandwidth saving. 


Implementations of fractional VC-4 encapsulation MUST support payload 
length of 1/3 SPE and MAY support payload lengths of 4/9, 5/9, 6/9, 
7/9, 8/9, and full SPE. The actual payload size of fractional VC-4 
encapsulation depends on the number of VCs carried within the 
payload. 


11.2.3.1. Fractional VC-4 Mapping 


[G.707] defines the mapping of TUG-3 to a VC-4 in Section 7.2.1. 
Each TUG-3 includes 86 columns. TUG-3#1, TUG-3#2, and TUG-3#3 are 
byte multiplexed, starting from column 4. Column 1 is the VC-4 POH, 
while columns 2 and 3 are fixed and therefore removed in the 
fractional VC-4 encapsulation. 


The mapping of TU-3 into TUG-3 is defined in Section 7.2.2 of 
[G.707]. The TU-3 consists of the VC-3 with a 9-byte VC-3 POH and 
the TU-3 pointer. The first column of the 9-row-by-86-column TUG-3 
is allocated to the TU-3 pointer (bytes H1, H2, H3) and fixed stuff. 
The phase of the VC-3 with respect to the TUG-3 is indicated by the 
TU-3 pointer. 


The mapping of TUG-2 into TUG-3 is defined in Section 7.2.3 of 
[G.707]. The first two columns of the TUG-3 are fixed and therefore 
removed in the fractional VC-4 encapsulation. The 7 TUG-2s, each 12 
columns wide, are byte multiplexed starting from column 3 of the 
TUG-3. This is the equivalent of multiplexing 7 VIGs within STS-1 
container in SONET terminology, except for the location of the fixed 
columns. 


The static fractional VC-4 mapping assumes that both the ingress and 
egress nodes are preconfigured with the set of equipped VCs carried 
within the fractional VC-4 encapsulation. The ingress emulation edge 
removes the fixed columns as well as columns of the VCs agreed upon 
by the two edges, and updates the B3 VC-4 byte. The egress side adds 
the fixed columns and the unequipped VCs and updates B3. 
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11.2.3.2. Fractional VC-4 CEP Header 


The fractional VC-4 CEP header uses the VC-4 CEP header defined in 
this document. Optionally, an additional 12-byte header extension 
word is added. 


The extended header has the following format: 


0 1 2 3 

MACCABI 980 UL 238 968 BOLAS A o 0 1 89000 4d 
-+-+-+-+-+-+-+-+ d+ + hh q + + + d+ + + + + + ho + +++ +++ 
ojojolo|L|r|N|P|FRG|Length[0:5]| Sequence Number[0:15] | 
+-+-+-+-+-+-+-+ d+ + ho hd + ph q + + + +++ +++ +++ 
erved |structure Pointer[0:11]| 
dh + Ph q + + + + + + + + +++ + + +++ ++ +++ +++ 
|o] Equipped Bit Mask #1 (EBM) [0:29] TUG-3#1 

dh + Ph q + + + + + + + + + hh + + +++ ++ +++ +++ 
ojo] Equipped Bit Mask #2 (EBM) [0:29] TUG-3#2 
+-+ 
A 


Re 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Equipped Bit Mask #3 (EBM) [0:29] TUG-3#3 


E 


+—+—+—+ 


Figure 9: Extended Fractional VC-4 Header 


The L, R, N, P, FRG, Length, Sequence Number, and Structured Pointer 
fields are used as defined in this document for STS-1 encapsulation. 


Each bit within the Equipped Bit Mask (EBM) field refers to a 
different tributary within the VC-4 container. A bit set to 1 
indicates that the corresponding tributary is equipped, hence carried 
within the fractional VC-4 payload. 


Three EBM fields are used. Each EBM field corresponds to a different 
TUG-3 within the VC-4. The EBM includes 7 groups of 4 bits per 
TUG-2. A bit set to 1 indicates that the corresponding VC is 
equipped, hence carried within the fractional VC-4 payload. An 
additional 2 bits within the EBM indicate whether VC-3 carried within 
the TUG-3 is equipped and whether it is in AIS mode. 
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11 


The VC-4 EBM has the following format: 


0 1 2 

GQL123456 7890123456739 0 1239456 7-8-9 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|A|T|TUG2#7 |TUG2#6 |TUG2#5 |TUG2#4 |TUG2#3 |TUG2#2 |TUG2#1 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 10: Equipped Bit Mask (EBM) for Fractional VC-4 


The 30 bits of the EBM are divided into 2 bits that control the VC-3 
within the TUG-3 and 7 groups of 4 bits, each corresponding to a 
different TUG-2 within the TUG-3 container. 


For a TUG-3 containing TUG-2, the first two A and T bits MUST be set 
to 0. The TUG-2 bits indicate whether the VCs within the TUG-2 are 
equipped. All 4 bits are used to indicate whether VC-11 (T1) 


tributaries are carried within a TUG-2. The first 3 bits read right 
to left are used to indicate whether VC-12 (El) tributaries are 
carried within a TUG-2. The first bit is used to indicate that a 


VC-2 is carried within a TUG-2. The VCs within the TUG-2 are 
numbered from right to left, starting from the first VC as the first 
bit on the right. For example, 28 bits of the EBM of a fully 
occupied TUG-3 with VC-11 tributaries are all ones, while that of a 
TUG-3 fully occupied with VC-12 tributaries has the binary value 
000111011101110111011101110111. 


For a TUG-3 containing VC-3, all TUG-2 bits MUST be set to 0. The A 
and T bits are defined as follows: 


T: TUG-3 carried bit. If set to 1, the VC-3 payload is carried 
within the TUG-3 container. If set to 0, all the TUG-3 columns are 
not carried within the fractional VC-4 encapsulation. The TUG-3 
columns are removed either because the VC-3 is unequipped or in AIS 
mode. 


A: VC-3 AIS bit. The A bit MUST be set to 0 when the T bit is 1 
(i.e., when the TUG-3 columns are carried within the fractional VC-4 
encapsulation). The A bit indicate the reason for removal of the 
entire TUG-3 columns. If set to 0, the TUG-3 columns were removed 
because the VC-3 is unequipped. If set to 1, the TUG-3 columns were 
removed because the VC-3 is in AIS mode. 


.2.3.3. B3 Compensation 


Fractional VC-4 encapsulation can be implemented in Line Terminating 
Equipment (LTE) or in Path Terminating Equipment (PTE). PTE 
implementations terminate the path layer at the ingress PE and 
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generate a new path layer at the egress PE. LTE implementations do 
not terminate the path layer, and therefore need to keep the content 
and integrity of the POH bytes across the PSN. In LTE 

implementations, special care must be taken to maintain the B3 bit- 


wise parity POH byte. The same procedures for B3 compensation as 
described in Section 11.2.1.2 for fractional STS-1 encapsulation are 
used. 


11.2.3.4. Actual Payload Sizes 


The actual CEP payload size depends on the number of virtual 
tributaries carried within the fractional SPE. The contributions of 
each tributary to the fractional VC-4 payload length as well as the 
path overhead contribution are described below. 


Each VC-11 contributes 27 bytes 

Each VC-12 contributes 36 bytes 

Each VC-2 contributes 108 bytes 

Each VC-3 (T3) contributes 738 bytes 

Each VC-3 (E3) contributes 576 bytes 

Each VC-3 (uncompressed) contributes 774 bytes 
VC-4 POH contributes 9 bytes 


The VC-3 contribution includes the AU-3 pointer. For example, the 
payload size of a fractional VC-4 configured to third-SPE 
encapsulation that carries a single compressed T3 VC-3 and 6 VC-12s 
would be: 321=(9 + 6*36 + 738) / 3 bytes payload per each packet. 


12. Signaling of CEP Pseudowires 


[PWE3-CONTROL] specifies the use of the MPLS Label Distribution 
Protocol, LDP, as a protocol for setting up and maintaining 
pseudowires. In particular, it provides a way to bind a de- 
multiplexer field value to a pseudo-wire, specifying procedures for 
reporting pseudowire status changes and for releasing the bindings. 
[PWE3-CONTROL] assumes that the pseudowire de-multiplexer field is an 
MPLS label; however, the PSN tunnel itself can be either an IP or 
MPLS PSN. 


The use of LDP for setting up and maintaining CEP pseudowires is 


OPTIONAL. This section describes the use of the CEP-specific fields 
and error codes. 
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The PW Type field in PWid Forwarding Equivalence Class (FEC) and PW 
generalized ID FEC elements MUST be set to SONET/SDH Circuit 
Emulation over Packet (CEP) [PWE3-IANA]. 


The control word is REQUIRED for CEP pseudowires. Therefore, the C 
bit in PWid FEC and PW generalized ID FEC elements MUST be set. If 
the C bit is not set, the pseudowire MUST not be established and a 
Label Release MUST be sent with an Illegal C bit status code 
[PWE3-IANA]. 


The PWid FEC and PW generalized ID FEC elements can include one or 
more Interface Parameters fields. The Interface Parameters fields 
are used to validate that the two ends of the pseudowire have the 
necessary capabilities to interoperate with each other. The CEP- 
specific Interface Parameters fields are the CEP/TDM Payload Bytes, 
the CEP/TDM Bit Rate, and the CEP Options parameters. 


12.1. CEP/TDM Payload Bytes 


This parameter MUST contain the expected CEP payload size in bytes. 
The payload size does not include network headers, CEP header or 
padding. If payload compression is used, the CEP/TDM Payload Bytes 
parameter MUST be set to the uncompressed payload size as if payload 
compression was disabled. In particular, when Fractional SPE (STS-1/ 
VC-3 or VC-4) payload compression is used, the Payload Bytes 
parameter MUST be set to the payload size before removal of the 
unequipped VT containers and fixed value columns. Therefore, when 
fractional SPE mode is used, the actual (i.e., on the wire) packet 
length would normally be less than advertised, and in dynamic 
fractional SPE, even change while the connection is active. 
Similarly, when DBA payload compression is used, the CEP/TDM Payload 
Bytes parameter MUST be set to the payload size prior to compression. 


T 


The CEP/TDM Payload Bytes parameter is OPTIONAL. Default payload 

sizes are assumed if this parameter is not included as part of the 
Interface Parameters fields. The default payload size for VT is a 
single super frame. The default payload size for SPE is 783 bytes. 


A PE that receives a label-mapping request with request for a CEP/TDM 
Payload Bytes value that is not locally supported MUST return CEP/TDM 
misconfiguration status error code [PWE3-IANA], and the pseudowire 
MUST not be established. 


12.2. CEP/TDM Bit Rate 
The CEP/TDM Bit Rate parameter MUST be set to the data rate in 64- 


Kbps units of the CEP payload. If payload compression is used, the 
CEP/TDM Bit Rate parameter MUST be set to the uncompressed payload 
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data rate as if payload compression was disabled. Table 3 specifies 
the CEP/TDM Bit Rate parameters that MUST be set for each of the 
pseudowire circuits. 


+------------- +----------------------- + 
| eters | Bit Rate Parameter | 
+------------- +----------------------- + 
| vT1.5/vc-11 | 26 

VT2/VC-12 35 

VT3 53 
| VT6/VC-2 | 107 | 
| STS-Nc | 783*N N=1,3,12,48,192 | 
+------------- +----------------------- + 


Table 3: CEP/TDM Bit Rates 


The CEP/TDM Bit Rate parameter is REQUIRED. Attempts to establish a 
pseudowire between two peers with different bit rates MUST be 
rejected with incompatible bit rate status error code [PWE3-IANA], 
and the pseudowire MUST not be established. 


12.3. CEP Options 


The CEP Options parameter is REQUIRED. The format of the CEP Options 
parameter is described below: 


0 i 

0r CP. afo o TO AB AGS oF O: E ce SB SBR. a, - 8 
4+---4+---4---4+---4---4---4--- +--+ -- = 4-4 - $$ tt tt 
|AIS|UNE|RTP|EBM| Reserved [0:6] | CEP Type | Async | 
| [0:2] [T3 |E3 | 
SS 


Figure 11: CEP Options 
AIS: When set, indicates that the PE sending the label-mapping 
request is configured to send DBA packets when AIS indication is 
detected. 
UNE: When set, indicates that the PE sending the label-mapping 
request is configured to send DBA packets when unequipped circuit 


indication is detected. 


RTP: When set, indicates that the PE sending the label-mapping 
request is configured to send packets with RTP header. 
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EBM: When set, indicates that the PE sending the label-mapping 
request is configured to send packets with EBM extension header. 


CEP Type: indicates the CEP connection type: 
0x0 SPE mode (STS-1/STS-Mc) 
0x1 VI mode (VT1.5/VT2/VT3/VT6) 
0x2 Fractional SPE (STS-1/VC-3/VC-4) 


Async Type: indicates the Async E3/T3 bandwidth reduction 
configuration. Relevant only when CEP type is set to fractional 
SPE, and fractional SPE is expected to carry Asynchronous T3/E3 
payload: 


T3: When set, indicates that the PE sending the label-mapping 
request is configured to send Fractional SPE packets with T3 
bandwidth reduction. 


E3: When set, indicates that the PE sending the label-mapping 
request is configured to send Fractional SPE packets with E3 
bandwidth reduction. 


Reserved field: MUST be set to 0 by the PE sending the label-mapping 
request and ignored by the receiver. 


A PE that does not support one of the CEP options set in the label- 
mapping request MUST send a label-release message with status code of 
CEP/TDM misconfiguration [PWE3-IANA], report to the operator, and 
wait for a new consistent label-mapping. A PE MUST send a new label- 
mapping request once it is reconfigured or when it receives a label- 
mapping request from its peer with consistent configuration. 


A pseudowire can be configured asymmetrically. One PE can be 
configured to use bandwidth reduction modes, while the other PE can 
be configured to send the entire circuit unmodified. A PE can 
compare the CEP Options settings received in the label-mapping 
request with its own configuration and detect an asymmetric 
pseudowire configuration. A PE that identifies an asymmetric 
configuration MAY report it to the operator. 
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Tez 


14. 


Congestion Control 


The PSN carrying the CEP PW may be subject to congestion. Congestion 
considerations for PWs are described in Section 6.5 of [PWE3-ARCH]. 
CEP PWs represent inelastic constant bit rate (CBR) flows and cannot 
respond to congestion in a TCP-friendly manner prescribed by [CONG]. 
CEP PWs SHOULD be carried across traffic-engineered PSNs that provide 
either bandwidth reservation and admission control or forwarding 
prioritization and boundary traffic conditioning mechanisms. 
Intserv-enabled domains [INTSERV] supporting Guaranteed Service [GS] 
and Diffserv-enabled domains [DIFFSERV] supporting Expedited 
Forwarding [EF] provide examples of such PSNs. It is expected that 
PWs emulating high-rate SONET STS-Nc or SDH virtual circuits will be 
tunneled over traffic-engineered MPLS PSN. 


CEP PWs SHOULD monitor packet loss in order to detect "severe 
congestion". If such a condition is detected, a CEP PW SHOULD shut 
down bi-directionally. This specification does not define the exact 
criteria for detecting "severe congestion" using the CEP packet loss 
rate and the consequent restart criteria after a suitable delay. 
This is left for further study. 


If the CEP PW has been set up using the PWE3 control protocol 
[PWE3-CONTROL], the regular PW teardown procedures SHOULD be used 
upon detection of "severe congestion". 


The SONET/SDH services emulated by CEP PWs have high availability 
objectives that MUST be taken into account when deciding on temporary 
shutdown of CEP PWs. CEP performance monitoring provides entry and 
exit criteria for the CEP PW unavailable state (UAS-CEP). Detection 
of "severe congestion" MAY be based on unavailability criteria of the 
CEP PW. 


Security Considerations 


The CEP encapsulation is subject to all of the general security 
considerations discussed in [PWE3-ARCH]. In addition, this document 
specifies only encapsulations, and not the protocols used to carry 
the encapsulated packets across the PSN. Each such protocol may have 
its own set of security issues, but those issues are not affected by 
the encapsulations specified herein. Note that the security of the 
transported CEP service will only be as good as the security of the 
PSN. This level of security may be less rigorous than that available 
from a native TDM service due to the inherent differences between 
circuit-switched and packet-switched public networks. 
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15. 


16. 


VT ss 


Although CEP MAY employ an RTP header when explicit transfer of 
timing information is required, SRTP [RFC3711] mechanisms are not a 
substitute for securing the PW and underlying MPLS network. 


IANA Considerations 


IANA considerations for pseudowires are covered in [PWE3-IANA]. CEP 
does not introduce additional requirements from IANA. 
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Appendix A. SONET/SDH Rates and Formats 
For simplicity, the discussion in this section uses SONET 
terminology, but it applies equally to SDH as well. SDH-equivalent 


terminology is shown in the tables. 


The basic SONET modular signal is the synchronous transport signal- 


level 1 (STS-1). A number of STS-1s may be multiplexed into higher- 
level signals denoted as STS-N, with N synchronous payload envelopes 
(SPES). The optical counterpart of the STS-N is the Optical Carrier- 


level N, or OC-N. Table 4 lists standard SONET line rates discussed 
in this document. 


4+------------- 4+-------- 4+--------- 4+---------- 4+----------- 4+----------- + 
| OC Level | oc-1 | oc-3 | oc-12 | oc-48 | oc-192 | 
4+------------- 4+-------- 4+--------- 4+---------- 4+----------- 4+----------- + 
| SDH Term | - | STM-1 | STM-4 | STM-16 | STM-64 | 
| Line | 51.840 | 155.520 | 622.080 | 2,488.320 | 9,953.280 | 
| Rate(Mb/s) | | | | | | 
4+------------- 4+-------- 4+--------- 4+---------- 4+----------- 4+----------- + 


Table 4: Standard SONET Line Rates 


Each SONET frame is 125us and consists of nine rows. An STS-N frame 
has nine rows and N*90 columns. Of the N*90 columns, the first N*3 

columns are transport overhead and the other N*87 columns are SPEs. 

A number of STS-1s may also be linked together to form a super-rate 

signal with only one SPE. The optical super-rate signal is denoted 

as OC-Nc, which has a higher payload capacity than OC-N. 


The first 9-byte column of each SPE is the path overhead (POH) and 
the remaining columns form the payload capacity with fixed stuff 
(STS-Nc only). The fixed stuff, which is purely overhead, is N/3-1 
columns for STS-Nc. Thus, STS-1 and STS-3c do not have any fixed 
stuff, STS-12c has three columns of fixed stuff, and so on. 


The POH of an STS-1 or STS-Nc is always 9 bytes in nine rows. The 
payload capacity of an STS-1 is 86 columns (774 bytes) per frame. 

The payload capacity of an STS-Nc is (N*87)-(N/3) columns per frame. 
Thus, the payload capacity of an STS-3c is (3*87 - 1)*9 = 2,340 bytes 
per frame. As another example, the payload capacity of an STS-192c 
is 149,760 bytes, which is 64 times the capacity of an STS-3c. 


There are 8,000 SONET frames per second. Therefore, the SPE size, 


(POH plus payload capacity) of an STS-1 is 783*8*8,000 = 50.112 Mb/s. 
The SPE size of a concatenated STS-3c is 2,349 bytes per frame or 
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150.336 Mb/s. The payload capacity of an STS-192c is 149,760 bytes 
per frame, which is equivalent to 9,584.640 Mb/s. Table 5 lists the 
SPE and payload rates supported. 


$ Ho Ho == AS SS do +----------- + 
| SONET STS | sTs-1 | STS-3c | OC-12c | OC-48c | O0C-192c | 
| Level | | | | | | 
$ Ho Ho +---------- do +----------- + 
SDH VC VC-3 VC-4 VC-4-4c VC-4-16c VC-4-64c 
Level 
| Payload | 774 | 2,340. | 9,360 | 37,440 | 149,760 | 
| Size(Bytes) | | | | | | 
| Payload | 49.536 | 149.760 | 599.040 | 2,396.160 | 9,584.640 | 
| Rate (Mb/s) | | | | | | 
| SPE | 783 | 2,349 | 9,396 | 37,584 | 150,336 | 
Size (Bytes) | | 
| SPE | 50.112 | 150.336 | 601.344 | 2,405.376 | 9,621.504 
| Rate(Mb/s) | | | | | | 
$ Ho Ho +---------- do +----------- + 


Table 5: Payload Size and Rate 


To support circuit emulation, the entire SPE of a SONET STS or SDH VC 
level is encapsulated into packets, using the encapsulation defined 
in Section 5, for carriage across packet-switched networks. 


VIs are organized in SONET super-frames, where a SONET super-frame is 
a sequence of four SONET SPEs. The SPE path overhead byte H4 
indicates the SPE number within the super-frame. The VT data can 
float relative to the SPE position. The overhead bytes V1, V2, and 
V3 are used as pointer and stuffing byte similar to the use of the 
H1, H2, and H3 TOH bytes. 


Appendix B. Example Network Diagrams 


Figure 12 below illustrates a SONET interconnect example. Site A and 
Site B are connected back to a Hub Site, Site C by means of a SONET 
infrastructure. The OC-12 from Site A and the OC-12 from Site B are 
partially equipped. Each of them is transported through a SONET 
network back to a hub site C. Equipped SPEs (or VTs) are then 
groomed onto the OC-12 towards site C. 
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SONET Network 
/ x/ \ of \__ 
H====-- + Physical / X—/ \ 
|Site A| oc-12  / +---+ Oc-12 \ Hub Site 
| | \s/|------------- +----- + \ +------ + 
| | \ I/ \| oe A | | 
Pacer + /\ mae aa ee ae | \ z | Z oc-12]| 
/ s |=========| Site C 
Ho + Physical/ AA | IN \ 
|Site B|] oc-12 \ |\s/| oh ON | 
| / \|------------- +----- + / +------ + 
| | \ a OcC-12 = / 
ho + \ = a ee 
\ / NA 


Figure 12: SONET Interconnect Example Diagram 


Figure 13 below illustrates the same pair of OC-12s being emulated 


over a PSN. 


This configuration frees up bandwidth in the grooming 


network, since only equipped SPEs (or VTs) are sent through the PSN. 
Additional bandwidth savings can be realized by taking advantage of 
the various payload compression options described in Section 11. 


SONET/TDM/Packet Network 


/ Nal NM / io 
prenie + Physical /+-+ \__/ NX 
|Site a| oc-12 / | | +---+ \ Hub Site 
| |P|=| R | +---+ +-+ += + \ +------ + 
|] all] de] p e A a 
+------ + /\+-+ ++ Me / OC-12 
/ [ellie a8 ie a ee 
+------ + Physical/ +-+ +---+ | AE i Gee eA | 
|Site B|  oc-12\ |P| | R |== UISA. N A | 
| lE|=| | +---+ +-+ +----- + +-----—- + 
ml MESS A 
PAnR SS + \ +-+ aul / 
\ / et 


Figure 13: SONET Interconnect Emulation Example Diagram 
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Figure 14 below shows an example of T1 grooming into OC-12 in access 
networks. The VI encapsulation is used to transport the Tls from the 
Hub site to customer sites, maintaining SONET/SDH Operations and 
Management (OAM). 


SONET/TDM/Packet Network 


/ Ei N 7 ya 
posd + Physical /+-+ Vy \_ 
|Site A| T1 / | | ++ \ Hub Site 
| lej=| R | +---+ +-+ 4¢----- + +------ + 
| | poe it A ds. Aa A | | 
$------ + /\t-+ +--+ | Ea ARS: ACET] 
/ | R |=|P| | s  |=========[Site c| 
+------ + Physical/ +--+ +---+ E EAN \ 
|Site B| TI A [P| | R |=== =l/ \ \ 
| lE|=| | +---+ +-+ +----- + / +-----—- + 
o MS = j 
{estss + \ ++ eh “Ae. a 
Ne, Aces i / wy 


Figure 14: T1 to OC-12 Grooming Emulation Example Diagram 
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